Database tables include rows and columns. It may be desired to control access to a database on a row by row basis. Conventionally, controlling row level access may have been implemented using labels (e.g., classification labels, sensitivity labels). A sensitivity label may have been assigned to an individual row in a database table. The label may have enabled row level security. The labels may have been stored in a dedicated column in the database table. Conventional labels were typically static items that identified a group or some other entity or characteristic upon which access was controlled. For example, a conventional label may have indicated that a user associated with a first group could access a row while a user associated with a second, different group could not. Similarly, a conventional label may have indicated a security level that a user had to meet or exceed before the user could access the row. For example, the label may have indicated a required security level of x, and a first user who had a security level of x or greater may have been allowed to access the row while a second user who had a security level less than x may not have been allowed to access the row. While inclusive traits (e.g., group membership) and quantifiable traits (e.g., security level) are described, it is to be appreciated that labels may have addressed other attributes.
Conventional systems may have compared user attributes to required attributes stored in the label associated with the row to be accessed in the dedicated column in the table that the user was attempting to access. The user attributes may have been accessible from a user label and/or session label. These labels define user attributes. In the example above, the labels may have provided values for security level and group membership. While two attributes are defined, it is to be appreciated that a user label and/or session label may include other, different attributes. However, this was one issue with label based security systems. Both the creator of the table and the user of the table needed to conform to the same fixed language concerning security. Thus, label based security tended to be limited in terms of dynamically responding to changing situations and to handling complex security considerations.
Some conventional systems extended the label approach into the virtual private database (VPD) domain. A VPD facilitates binding a stored procedure to a database object like a table, a view, and so on. A VPD object may be accessed using access statements including, for example, query statements, data manipulation operation (DMO) statements, and so on. When the VPD object was accessed, the accessing statement may have been intercepted and a stored procedure associated with the database object may have been executed. The stored procedure may have rewritten the accessing statement to achieve different ends including, for example, improving efficiency, improving security, and so on. Rewriting the accessing statement may have included inserting a dynamically generated clause to the access statement. The dynamically generated clause may have included variables available from the accessing environment. For example, variables associated with the user label, the session label, the machine, and so on, may have been present in the dynamically generated clause.
The dynamically generated clause may have been, for example, a “where” (e.g., SQL WHERE) clause. More generally, the generated clause may be treated as a “predicate”. Thus, row level security may be enhanced in these conventional systems by rewriting an access statement to include a predicate (e.g., WHERE clause) that must be evaluated in a certain way before access to a row will be granted. While useful, this conventional approach still had limitations. For example, the exact nature of the relationship between the user accessing the data and the data itself needed to be defined ahead of time by a database administrator (DBA), an application developer, or other individual. Imperfect knowledge about security policies may have existed. Therefore, it may have been difficult, if possible at all, to pre-design a static system to handle a wide and/or complete spectrum of access policies. Thus, improvements to row level security are still desirable.